A few weeks back (Feb 27) I spoke at the Rocky Mountain Tech Trifecta (http://rmtechtrifecta.pbworks.com/), where I gave the SQL Track keynote, and then did my Database Design session.  Great time and I had a blast giving a keynote. It was especially fun just doing a lightweight session just encouraging folks to do design.

Last week, I spoke virtually for the Minnesota PASS group, giving the same presentation, plus 10% and including my patent pending Lego audience (The Minifiggers) and audience members that provided me with feedback and answers to my questions that I commonly ask during the presentation. Doing a virtual presentation is interesting, because as exciting as my Minifiggers are, they have plastic faces and don’t let me know when I am confusing them, or when they find my jokes funny.

That was the past.. Over the next 4 weeks, I will be speaking at 2 (and probably 3) SQL Saturday events in Birmingham, Richmond, and hopefully Atlanta. Each time I will be doing my database design session (which has changed 40% since last week), and my database design pattern session (which I haven’t started going over again, but it will likely change from the last time I gave it last year.

The abstracts are:

Database Design Fundamentals

In this session I will give an overview of how to design a database, including the common normal forms and why they should matter to you if you are creating or modifying SQL Server databases. Data should be easy to work with in SQL Server if the database has been organized as close as possible to the standards of normalization that have proven for many years. Many common T-SQL programming "difficulties" are the result of struggling against the way data should be structured and can be avoided by applying the basic normalization techniques and are obvious things that you find yourself struggling with time and again (i.e. using the SUBSTRING function in a WHERE clause meaning you can’t use an index efficiently).

Database Design Patterns

Beyond database design fundamentals (for example, Normalization) lies the area where you have to create "real" solutions. In this session, I will cover a good number of patterns that we commonly find useful to try to apply to the problem of building a database solution. Ideas like generalization, subclassing, single table domain tables, optional data, and more will be discussed, some of them good, some not so good (don’t assume which will be which), but all that are common and/or useful for your database implementations.

After these three stops, I don’t see myself doing much speaking until Devlink (if accepted, if not I will be attending!) and/or PASS (again, if accepted) as well as at least one other opportunity that has not been scheduled yet (all hush hush and whatnot).

If you need a speaker for your user group that is within 6 hours drive from Nashville, I will be happy to come sometime, or anywhere if you provide me transportation or let me present virtually.

So hope to you see you (not you, I was pointing at.. well, ok you too) at one of these stops for a fun talk about database design. Yes, I said fun. And the first step to good performance is Normalization, not Denormalization. Both true statements.